Data rate control

ABSTRACT

The rate of data transmission to a user via a communications link of a network is controlled wherein resource requests are communicated to a service provider. The resource requests are determined in accordance with an indication of the congestion level on the network and the user&#39;s defined parameters, such as their willingness to pay for the resource, wherein the resource request is weighted by a variable parameter, whose value is set in accordance with the congestion level on the network. This allows the rate controller to react efficiently and swiftly to network conditions as well as user defined parameters. By providing a computer programmed to act as a purchasing agent an automatic resource request to a service provider is enabled. An embodiment is described in which audio or video data is streamed to a user on the basis of the resource requests made on the user&#39;s behalf and is adjusted on the basis of user and network defined parameters. Such techniques could also be used to provide appropriate data streaming for many different types of network traffic.

This application is the US national phase of international applicationPCT/GB2003/002980 filed 9 Jul. 2003 which designated the U.S. and claimsbenefit of GB 0216728.6, dated 18 Jul. 2002, the entire content of whichis hereby incorporated by reference.

BACKGROUND

1. Technical Field

The present invention relates to a method for controlling the rate ofdata transmitted to a user on a communications link, and in particularto a method of resource control wherein resource requests from a user toa service provider are determined in response to the amount ofcongestion on the communications link.

2. Related Art

The last two decades have seen the introduction of so-called‘integrated’ networks, such as asynchronous transfer mode (ATM) andInternet Protocol (IP) networks, which are designed to carry bothcomputer communications and telephony. The capacity of those networksneeds to be allocated between users who require a constant bit-rate forthe duration of a communication (e.g. telephone users), those who cantolerate some variation in the bit-rate supplied to them by the network(e.g. those transferring web-pages, software or e-mails), and thoseusers who can tolerate less variation in the bit-rate supplied to themby the network (e.g. those transferring video clips or other real timeapplications).

To deal with different user's requirements, integrated networks offertheir users the ability to specify which service they wish to receivefrom the network (which, being an integrated network, can offer aplurality of different services). This specification can be made once atthe start of a communication (the normal procedure in networks offeringa connection-oriented service, such as ATM networks) and/or repeatedlyduring a communication.

As mentioned, an Internet Protocol network is one type of integratednetwork. An IP network can offer a constant bit-rate service type (usingthe Resource Reservation Protocol (RSVP)), and a best efforts servicetype. Another service type gives packets sent by one class of userspriority over packets sent by another class of user. Using RSVP, a usercan additionally specify the amount of bandwidth he or she wishes tohave available.

Where a person has to make such a service specification many timesbecause he or she is involved in a number of different communicationsand/or has to make a plurality of service specifications during acommunication, it is beneficial if that specification is made on thatperson's behalf by a computer programmed to act as that person's agent.

The present invention concerns how the computer acting as an agentdetermines the data rate request for the user.

During the last five years not only has the amount in Internet trafficincreased dramatically, but there has also been a significantdiversification in the type of traffic flowing through computernetworks. Until fairly recently, file transfer, email and simple webtraffic formed the almost all the data flows on the Internet. Nowapplications may include multi-party and/or multi media datatransmission. Such applications include “real-time” audio and video,interactive games, instant messaging, multi-party virtual worlds,network games, auctions, audio and video-conferencing and IP telephony.

In view of the increase in data transmission, efficient control andmanagement of the network resources is becoming increasing important.One of the problems faced by network users and service providers iscongestion, a situation in which there is too much data for the networkto handle. The consequence of which is delays or even loss of data.

Traditionally, rate control in the Internet is taken care of by theTransmission Control Protocol (TCP). TCP is described in many referencesplaces, for example, “Fred Halsall, Data communications, computernetworks and open systems, 6^(th) ed., Addison-Wesley, 1995. TCP is awindow based rate control algorithm, i.e. window based rate control isachieved by limiting the amount of data that can be in the network atany one time. TCP is stable and normally makes fairly efficient use ofthe available bandwidth, and distributes network resources fairlybetween different users. For file transfer and email, TCP performs wellbecause, provided the file or email arrives within a reasonable time atits destination, it is not important at which rate the data wastransmitted. However, TCP rate control gives rise to fluctuations in thetransfer rate that are unacceptable for applications where the rate ofdata transmission is important, for example, real time applications,such as video and audio streaming. The reason for this is that if asingle packet is lost the congestion window is halved. Further TCPguarantees that lost packets will be retransmitted until they arrive atthe receiver. For some applications including real-time multimediaapplications, this is not necessary. Problems with rate fluctuationswhich occur in networks running TCP have made it necessary to developalternative rate control algorithms. It is believed that in time TCPwill become a less preferred option, as it becomes less able to dealwith the greater variety of services users demand.

Further, as congestion on the Internet increases, network managers arelooking for alternative ways to manage it. Also, multimedia multi-partyinternet protocol (IP) applications, such as those mentioned above, canbe very demanding in terms of their Quality of Service (QoS)requirements. Standards are being developed to ensure that networkresources can be applied where they are most needed. However, problemsstill surround how the demand for different classes of QoS should bemanaged.

One solution to this problem may be congestion based pricing. Theunderlying idea being to charge users or, on a more abstract level, tocharge applications. The charge may be either in terms of real currencyor in some other terms, for example fictional currency. The charge ismade for the network resources used. Also the charge increases dependingon the level of network congestion. When bandwidth becomes scarce, thecharge will increase, when congestion reduces the charge is decreased.This gives users, or applications, the incentive to back off the networkat times of network congestion. Congestion based pricing is discussed byF. P. Kelly in “Charging and rate control for elastic traffic”, EuropeanTransactions on Telecommunications, vol. 8, pp33-37, January 1997.

Conventional rate control techniques are based on variables whichreflect network performance, such variables include packet loss orroundtrip time. Price based approaches exploit “shadow prices” (anexpression borrowed from economics which is applied to situations whereactual prices cannot be charged, or where actual prices do not reflectthe real sacrifice made when some activity is pursued. Shadow prices areused in valuing any item, such as a network resource, which isimplicitly rationed or constrained in some way.) and user determinedpolicies that specify how much the user values the data rate they getfrom the network. One way of expressing this variable is the user'swillingness to pay for a particular service.

One such priced based technique for managing congestion is discussed in“F P Kelly, A K Maulloo, and D K H Tan, Rate control for communicationnetworks: Shadow prices, proportional fairness and stability, Journal ofthe Operational Research Society 49 (1998), no. 3, 237-252”. In thispaper, Kelly et al propose an “equation based algorithm”. Equation basedalgorithms are so called because they differ from window basedalgorithms, such as TCP, in that the sending rate is determined directly(without any other external constraints) using a mathematical equation.Contrary to window based rate control, equation based rate control doesnot place an explicit limit on the amount of outstanding data (data thathas left the sender, but has not arrived at the receiver yet). Atpresent, TCP, a window based algorithm, is not able to support suchalternative equation based algorithms for rate control.

The equation based rate control algorithm proposed by Kelly et al isknown as the “primal” algorithm. The primal algorithm determines therequest for a data rate which a user sends to his service provider, whenrequesting a download of data. The primal algorithm is an adaptivesystem which takes user determined parameters, such as the user'swillingness to pay for a service together with network managerdetermined parameters, such as the price charged by the resource perunit flow, and network determined parameters, such as the transfer rateof the flow along a particular route and the congestion price, todetermine the sending rate request which the user sends to his serviceprovider.

The primal algorithm has been shown to be stable. However, the rate ofconvergence, that is the rate at which the algorithm reaches a stablerate, is a particular problem with the primal algorithm. This causesproblems in particular, at the beginning of a download, where it takesthe primal algorithm too long to go from a very low data rate to thedesired data rate, and in situations where congestion is to be avoided,where the user desires a relatively low data rate, with however, littlevariation.

The present invention provides a solution to the problems identifiedabove with respect to resource control in data transmission.

SUMMARY

According to an exemplary embodiment, there is provided a method ofcontrolling the rate of data transmission from a source of data to auser via a communications link, wherein processing means are provided togenerate a signal representing a rate request which will be used indetermining the rate at which data will be transmitted from the sourceto the user, said processing means generating the signal by carrying outthe steps of: obtaining an indication of the amount of congestion onsaid communications link,

selecting a value indicative of the user's willingness to pay for agiven transmission data rate, and

determining the rate to be requested as a function of the indication ofthe amount of congestion and the user's willingness to pay weighted by avariable parameter, the processing means thereafter communicating thesignal to the source of data and the rate of the data transmission fromthe data source to the user then being controlled on the basis of thesignal.

The inventors have realised that by weighting a function of the user'swillingness to pay and an indication of the congestion to determine adata rate to be requested, the data rate requested can be controlledmore efficiently. This enables improved allocation of resources of thenetwork over prior art systems.

Preferably (but not necessarily), the rate to be requested is determinedusing the following iterative equation:X _(n+1) =x _(n)+delta*kappa*x _(n) ^(ξ)(w−x _(n)*μ)where x_(n) is the data transmission rate (bits per second) ascalculated at an nth iteration; and x_(n+1) is the rate to bedetermined; x_(n)*μ is the charge to the user indicative of amount ofcongestion and is the product of x_(n) and congestion charge μ; w is thewillingness to pay; delta is the time elapsed between two iterations;kappa is a constant gain parameter; and ξ (xi) is a parameter whosevalue is set depending on the indication of congestion or the user'swillingness to pay.

This has the advantage of enabling the rate controller to adoptdifferent policies depending on the user's preferences and the networkconditions. The data rate requests will have different values dependingon the users preferences and the network conditions. The possiblepolicies differ by their reactivity speed to sudden changes to thecongestion level.

According to a further aspect of the present invention, there isprovided a rate controller for controlling the rate of data transmissionfrom a source to a user via a communications link, said rate controllerincluding processing means for generating a signal representing a raterequest which will be used in determining the rate at which data will betransmitted from the source to the user, said processing means includingmeans for obtaining an indication of the amount of congestion on saidcommunications link,

-   selecting means for selecting a value indicative of the user's    willingness to pay for a given transmission data rate,-   determining means for determining the rate to be requested as a    function of the indication of the amount of congestion and the    user's willingness to pay weighted by a variable parameter, the    processing means further including means for communicating the    signal to the source, wherein the rate of the data transmission from    the source to the user is controlled on the basis of the signal.

According to a further aspect of the present invention, there isprovided a method of controlling the rate of data transmission from asource of data to a user via a communications link, wherein processingmeans are provided to generate a signal representing a rate requestwhich will be used in determining the rate at which data will betransmitted from the source to the user, said processing meansgenerating the signal by carrying out the steps of:

-   obtaining an indication of the amount of congestion on said    communications link, selecting a value indicative of the user's    willingness to pay for a given transmission data rate,-   determining the rate to be requested on the basis of the ratio of    said value to said indication of the amount of congestion on said    communications link.

The inventors have realised that by assessing the ratio of a userdetermined parameter and the indication of the congestion on the networkto determine a data rate request, the rate of convergence of the systemis dependent only on the congestion level. This has the advantage thatthe rate control method does not affect the stability of the network.

Preferably (but not necessarily), the method of controlling the rate ofdata transmission determines the rate to be requested in accordance withthe following equation:

$x_{n + 1} = {x_{n} + {\delta*\kappa*\left( {\frac{w}{\mu} - x_{n}} \right)}}$where x_(n) is the data transmission rate (bits per second) ascalculated at an nth iteration and x_(n+1) is the rate to be determined;μ is the congestion charge indicative of amount of congestion; w is thewillingness to pay; delta is the time elapsed between two iterations;and kappa is a constant gain parameter.

Further according to another aspect of the present invention, there isprovided a rate controller for controlling the rate of data transmissionfrom a source to a user via a communications link, said rate controllerincluding processing means for generating a signal representing a raterequest which will be used in determining the rate at which data will betransmitted from the source to the user, said processing means includingmeans for obtaining an indication of the amount of congestion on saidcommunications link,

-   selecting means for selecting a value indicative of the user's    willingness to pay for a given transmission data rate,-   determining means for determining the rate to be requested as on the    basis of the ratio of the user's willingness to pay to said    indication of the amount of congestion on said communications link,    the processing means further including means for communicating the    signal to the source, wherein the rate of the data transmission from    the source to the user is controlled on the basis of the signal.

Both apparatuses summarised above are preferably embodied in a generalpurpose computer, suitably programmed.

This invention also extends to a computer programmed to perform themethod of the invention, and to a computer program product loadable intothe internal memory of a digital computer, comprising software codeportions for performing the steps of the method of the invention, whensaid product is run on a computer.

BRIEF DESCRIPTION OF THE DRAWINGS

By way of example only, specific embodiments of the present inventionwill now be described with reference to the accompanying Figures inwhich:

FIG. 1 shows schematically the basic components of a general purposecomputer disposed in a network connected to a content provider, capableof performing the invention;

FIGS. 2 a and 2 b show demand functions;

FIG. 3 illustrates an example of a network including users and contentproviders where the concept of proportional fairness is applied;

FIG. 4 is a flowchart illustrating schematically the operation of anembodiment of the invention;

FIG. 5 is a flowchart illustrating schematically the operation of anembodiment of a further embodiment of the invention; and

FIG. 6 is a flowchart illustrating schematically the operation of yet afurther embodiment of the invention.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

FIG. 1 shows an internetwork comprising a content provider's local areanetwork 1 connected to a customer end configuration via an internetservice provider's (ISP) network 6. The content provider's local areanetwork 1 includes a video server 4 having a stream adaptation module 24and a memory 26 where the video data is stored. It is not essential thatthe memory 26 be located at a particular video server. The memory 26 maybe remote from the server 4. The customer end includes a video play 2(with video output 10) and a dynamic price handling module 8, and aportion of the global Internet 6 with servers 22 which interconnects theuser with the content provider.

BACKGROUND OF THE PREFERRED EMBODIMENTS

In the preferred embodiment described below, reference is made totransmission of video data. However, the invention is not limited inthis respect and may be applied to the transmission of any data. Asmentioned above, the present invention has particular application toreal time data such as video, audio data as well as interactive andmultiparty applications.

FIG. 1 shows an internetwork comprising a content provider's local areanetwork 1 connected to a customer end configuration via an internetservice provider's (ISP) network 6. The content provider's local areanetwork 1 includes a video server 4 having a stream adaptation module 24and a memory 26 where the video data is stored. It is not essential thatthe memory 26 be located at a particular video server. The memory 26 maybe remote from the server 4. The customer end includes a video player 2and a dynamic price handling module 8, and a portion of the globalInternet 6 (with servers 22) which interconnects the user with thecontent provider.

The internetwork in FIG. 1 is suitable for use with methods forcontrolling congestion, such as congestion based pricing. The congestionlevel in the network is signalled to the user, for instance, by usingthe explicit notification protocol (ECN). The ECN protocol isstandardised as part of the IETF Standard Track as RFC 3168[21], and isthe subject of the Market Managed Multiservice Internet (M31)Consortium, a multi party collaboration including the applicants. Formore information on the M31 Consortium reference is made tohttp://www.m3i.org.

When a user sends a request for a download of data to the contentprovider, the internetwork shown in FIG. 1 responds as described below.The content provider receives the request and when the data is ready fortransmission begins to transmit data to the user via the network. Thenetwork provider linking the content provider to the user randomly markdata packets on its network. The larger their data rate, i.e. the numberof packets per unit time, the higher the probability will be that apacket is marked. Thus the number of marked packets received at the userend will be indicative of congestion level. Marking of data is done inaccordance with the explicit congestion notification protocol, which hasbeen standardised as part of the IETF Standard Track as RFC 3168[21].

The marks in the data are detected at the user end of the network by ametering module 14. The location of the metering module 14 is notimportant provided it is disposed between the content provider and theuser. For example, it may be disposed within the network or at theuser's end.

The metering module 14 produces an estimate of the marking rate for thedata destined for the user, which is the ratio of marked packets amongthe received packets over an observation period.

The user is charged an amount for each marked packet in the data streamreceived. This charge may bear a real monetary value and later be usedto actually charge the user. Alternatively, the price per mark may alsoremain a fictional charge and simply represent an indication of theamount of data on the network, i.e. the level of congestion. If there isenough traffic with one user on the connection, then the number of markswill be an indication of the congestion on the network, that is thetotal amount of traffic on the network. Thus the congestion indicationmay represent a symbolic incentive for the user to reduce herconsumption of the network's resource. In any case, the marking ratereflects the current congestion level in the network and is the maindynamic input to the control means 18 at the user's end to the controlthe data rate of the connection and thereby optimise the utility of thecustomer. The price charged by the network is proportional to thecongestion level. The charge for the user is based on the product of theprice charged by the network and the amount of data sent or received bythe user.

DETAILED DESCRIPTION OF THE EMBODIMENTS

The present invention is preferably embodied in a rate controller 16,comprised within a dynamic price handling (DPH) agent 8. In the example,shown in FIG. 1, the DPH agent is located at the user's end. Thisarrangement is preferable, however, the invention is not limited in thisrespect, and the DPH agent 8 may be located anywhere within theinternetwork provided the user's preferences can be input to it, andprovided its output can be transmitted onto the network. In particular,DPH may be located at the content provider's end.

The role of the DPH is to perform the rate control of the data streamthe user is interested in. When the user sets up a connection shespecifies her control policy 32. Then for the duration of theconnection, the DPH monitors the evolution of the marking rate 30and—when necessary—requests that the data rate delivered to the userover the network to be adjusted to a new target rate 36. The deliveryprocess itself may be carried out according to any method as long as itprovides a working interface for rate control purposes. The improvementachieved by the present invention is to have a configurable rate controlbased on the congestion marks signalled by the network rather than adefault rate control based on packet losses.

The marking rate is retrieved from the metering module 14, it representsthe proportion of marked packets within the data stream during a periodand is expressed in marks per packet. This period will not necessarilybe the same for input to the price reactor 18 and to the rate controller16.

The adjustment request from the rate controller is communicated to theserver 4 via the quality of service controller 12 of the video client 2over the control channel 38. The stream adaptation module 24 of thevideo server will adjust the data sent to the user accordingly.

The DPH agent 8 is now described in greater detail. Within the DPH agent8 three main functions are performed: the policy selection, the pricereaction and the rate control. While the policy selection is done mainlybefore the service is delivered to the customer, the price reaction andrate control are carried out during the duration of the connection. Itmay also be updated occasionally as the service is provided. The pricereaction and rate control however, are performed continually while theservice is being delivered, with the price reaction preferably, beingperformed on a longer timescale than rate control.

When a connection is set up for download of data to a user, the userdefines her strategy, i.e. how she will react to changes in thecongestion indication (or congestion price). This is done by selecting abuying policy reflecting her needs using the policy selector 20. Adefault policy, or more usually a selection of popular or commonly usedpolicies, is provided by the content provider when the connection is setup, but the user is able to customize her buying policy to accommodateher preferences. The buying policy defines the demand function 32 of theuser, and is used by the price reactor to determine the requested datarate. The demand function is the relationship between a given congestionindication (or congestion price) and the data rate the user is willingto accept for that congestion indication. Having selected a buyingpolicy, the DPH agent is able to handle the transmission control onbehalf of the user for the rest of the session. If the user wishes,however, the buying policy may be changed during the session.

The policy selector allows the user to define how she would like the DPHto react to the congestion signal by choosing an adequate user policy.The user will always have to choose her policy when the connection isset up and she may modify or change it during the session. The defaultpolicy is adopted if the user does not want to configure the DPH. Theuser policy is the only input the DPH needs from the user to handle therate control of the connection on the user's behalf.

The policy selector 20 translates the user policy into a demand function32 that gives the optimal rate the DPH should request for any congestionshadow price. A typical demand function is a decreasing function of thecongestion price: the more congested the network, the less the user iswilling to create traffic. In the implementation of the DPH, thedecreasing function is represented as a set of points that give thevalue of the demand function for a number of values of the congestionprice. The value of the demand function 32 for other congestion pricesis obtained by linear interpolation.

The price reactor module 18 periodically establishes the willingness topay 34 of the user according to the user's demand function 32 obtainedfrom the policy selector 20, and to the marking rate 30 reported via themetering module 14. In addition, the price reactor 18 infers an estimateof the congestion shadow price in the network from the marking rate 30reported via the metering module 14. This estimate reflects thecongestion level in the network.

The function of the rate controller 16 is to reach the optimaltransmission data rate as smoothly as possible to avoid compromising thestability of the network. Consequently, the rate control module 16monitors the congestion indication (or congestion price) on a shortertimescale than the price reactor 18 does. This is achieved using therate control algorithm of the present invention, described in detailbelow

In the embodiment shown in FIG. 1, the rate controller 16 determineswhich streaming data rate is to be requested, and communicates it to thequality of service controller which is embedded in the video player 2,which sends a request message. The decision to request a data rateadaptation is performed by the quality of service controller, whichsends a request to the content provider. However, it is not essentialthat the quality of service controller handles the communication to thecontent provider's server. The rate controller 16 may also communicatethe request data rate to the content provider.

FIG. 1 also shows the main components of the DPH agent 8 and how theyinterface together. The policy selector 20, with which the userinteracts, inputs the demand function 32 to the price reactor 18 at thestart of the session. During the whole duration of the session, themarking rate 30 is communicated to the price reactor 18 and the ratecontroller 16. At regular time intervals, the price reactor 18 updatesthe willingness to pay 34 which is communicated to the rate controller16. Periodically, according to the willingness to pay and the congestionprice estimate (determined from the marking rate), the rate controllerselects a new target data rate 36, which the rate controller 16 orquality of service controller communicates to the content provider.Overall, the DPH agent 8 therefore, determines the adaptation signal forthe data rate on the connection from the congestion indication signalledby the marking rate.

The dynamic inputs to the DPH agent 8 are the marking rate, the priceper mark and the demand function which includes the willingness to pay.However, usually, the price per mark and the demand function will notvary during a session.

The marking rate is retrieved from the metering module 14 and representsthe proportion of marked packets within the data stream during a period.This period will not necessarily be the same for the input to the pricereactor 18 and to the rate controller 16.

The demand function 32 is communicated from the policy selector 20 tothe price reactor 18. The price reactor 18 determines the optimalstreaming rate in bits per second for a set of discrete values of thecongestion indication in marks per bit. The value of the demand function32 for any congestion price is obtained by linear interpolation.

The willingness to pay 34 is determined by the price reactor 18 andcommunicated to the rate controller 16.

The target rate 36, expressed in bits per second, is preferablycommunicated to the quality of service controller 15 for furthercommunication to the stream adaptation module 24 at the contentprovider's server 4.

With respect to the components of the DPH agent, the followingadditional description is given.

The Policy Selector

The policy selector 20 produces the user's selected policy whichcontains the demand function of the user, inferred from the utilityfunction. For further details on how the demand function is extractedfrom the utility function, reference is made to “B. Briscoe, “PriceReaction Design”, Deliverable 3.2 (July 2000), M31 EU Vth FrameworkProject IST-1999-11429 http://www.m3i.org.

The demand function is the relationship between the user's optimalpreferred data rate and the estimated congestion price.

By way of explanation, FIG. 2 shows two demand functions. FIG. 2 a is ademand function whose purpose is to demand a constant data rateregardless of the congestion price. So, however high the congestionprice, the user is prepared to pay in order to maintain her optimal datarate. The user policy related to this demand function is referred to as“constant quality of service”. In terms of utility function, the“constant quality of service” policy is a step form, i.e. the customerhas no use of the data unless it is received completely.

FIG. 2 b shows a demand function which is intended to keep the chargingrate constant over a period of time (the amount of money charged to theuser for the data transmitted over a unit of time). The policy relatedto this demand function is referred to as “constant charge”. In terms ofutility function, the “constant charge” policy corresponds to a userwith a logarithmic utility for the bandwidth. It is added that theinvention supports a wide variety of policies and is not limited in thisrespect. Further, any policy can be customised to accommodate a user'spreference. The two policies discussed above, however, represent two ofthe most preferred policies.

The Price Reactor

The price reactor takes the user's policy which defines the demandfunction D(p) with respect to the shadow congestion price to determinethe user's willingness to pay.

The marking rate from the metering module 14 is the primary dynamicinput to the price reactor 18. The marking rate is evaluated by theprice reactor 18 on a periodic basis.

The first step (1) is to obtain the congestion price. The congestionprice, p(·), in charging unit per bit is inferred from the marking rate,m(·), in marks per bit, and the price per mark,ppm, in charging unit permark.

-   (1) p=m*ppm, where p is the congestion price as a function of time,    m is the marking rate as a function of time, and * hereinafter means    multiplied by.

The second step (2) is for the price reactor to determine anintermediate target rate in bits per second.

-   (2) target_rate=D(p).

The third step is to determine the willingness to pay, w, from thetarget rate.

-   (3)w=target_rate*m.

The willingness to pay is communicated to the rate controller.

Rate Controller

The rate controller 16 includes a memory 17 for storing the requesteddata rates and a processor. The rate controller 16 determines the datarate that is to be requested to the content provider on the basis of thewillingness to pay of the user, the instantaneous congestion price andthe data rates available from the content provider's server 4.

The rate controller 16 calculates the optimal data rate using a ratecontrol algorithm according to the present invention. The rate controlalgorithm enables an optimal target rate to be calculated in order toadapt to changing congestion conditions without putting the networkstability at risk.

The rate control algorithm used by the rate controller 16 is:x _(n+1) =x _(n)+delta*kappa*X _(n) ^(ξ)(w−x _(n)*μ)  (4)where x_(n) is the current target rate in bits per second as calculatedat the nth iteration; μ is the congestion charge and is determined fromthe marking rate obtained from the metering module 14; w is thewillingness to pay as updated by the price reactor 18; delta is thelength of the metering cycle in seconds; kappa is a constant; and ξ(xi)is a parameter having a value between −1 and +1. ξ is discussed fullybelow. It is noted that μ in Formula (4) is used to give an indicationof the congestion, and does not necessarily have any monetaryimplication.

It is further added that kappa is constant and represents the ability ofthe system to adapt to a change in the requested data rate. Kappa, alsodenoted as κ in the text below, is referred to as the adaptation gain,that is the nominal speed of reaction. The tuning of kappa reflects thecompromise between reactivity and stability. The higher the value ofkappa, the swifter the reaction of the system (at the risk of causinginstability). The lower the value of kappa, the more stable the datarate will remain (at the risk of barely adapting to a differentrequested data rate). If, for example, kappa were 0, the data rate wouldremain constant and would not adapt in spite of the requested data rate.

Formula (4) represents a discretisation of a system of differentialequations underlying the present algorithm as discussed below, and shownbelow in equation (5).

Theoretical Background

In order to fully appreciate the exemplary embodiment, some theoreticalbackground of the rate control algorithm of the present exemplaryembodiment is given in this section.

For background, reference is made to “F P Kelly, A K Maulloo, and D K HTan, Rate control for communication networks: Shadow prices,proportional fairness and stability, Journal of the Operational ResearchSociety 49 (1998), no. 3, 237-252”, which sets out the primal algorithmand the concepts of stability and fairness of a system governed by anequation based congestion algorithm.

The inventors of the subject application have deduced that the non-timedelayed version of the primal algorithm is globally stable andproportionally fair, but the global stability is not guaranteed whentime lags are taken into consideration. The inventors have found outthat the kappa parameter in the algorithm is crucial: it has to besufficiently small to achieve an acceptable level of local stability.However, setting kappa to the low values required to attain stability,results in a painstakingly slow convergence, which is also notacceptable. The inventors have found, that in fact, the rate ofconvergence in general in the primal algorithm is problematic. The lackof a mechanism like the slow-start in TCP is partly responsible forthese problems. (It is noted that the name “slow-start” in TCP iscounterintuitive: during “slow-start” the transfer rate actually changesvery rapidly, not slowly, in order that the data rate reaches theoptimum rate as quickly as possible. This nomenclature has its roots inTCP's history.)

The algorithm of the present exemplary embodiment overcomes the problemswith the primal algorithm. It is able to operate in different phases,like “slow-start”, i.e where the data rate changes rapidly, andcongestion avoidance, i.e. where the data rate is kept constant. Thealgorithm of the present invention is referred to hereinafter as theξ(xi) algorithm and is named after one of its parameters, whichdetermines the “phase”, i.e. the mode, in which the algorithm operates.

In the sections below, the ξ(xi) algorithm is presented and, sometheoretical results on its stability and fairness are derived. Also, thepresence of the ξ parameter, that allows the algorithm to operate indifferent phases is discussed. This discussion includes the discussionof phase transitions, that is when to move from one phase to another.

ξ(xi) Algorithm

To present the ξ algorithm, a mathematical model is required. Let J be aset of network resources, and c_(j) the (finite) capacity of resource j,for j∈J. Furthermore, take R⊂P(J), the set of possible routes, andx_(r), r∈R, the transfer rate of the flow through route r.

Let A=(A_(jr), j∈J, r∈R), where A_(jr)=0 if j∉r and 1 if j∈r.

A vector of transmission rates x=(x_(r), r∈R) is feasible if x isgreater than or equal to 0 and Ax is less than or equal to c.

In addition, the functions p_(j)(·), j∈J, where p_(j)(y) is the pricecharged by resource j, per unit flow, when the total flow throughresource j is y. Finally, take W=(w_(r), r∈R), the amounts users arewilling to pay per unit time for each route, and kappa, the gain factordiscussed above.

The ξ algorithm can now be described by the system of differentialequations:

$\begin{matrix}{{\frac{\mathbb{d}}{\mathbb{d}t}{x_{r}(t)}} = {\kappa\;{x_{r}(t)}^{\xi}\left( {{wtp}_{r} - {{x_{r}(t)}{\sum\limits_{j \in r}{m_{j}(t)}}}} \right)}} & (5)\end{matrix}$where the summation is over a set of routes, and where

$\begin{matrix}{{m_{j}(t)} = {p_{j}\left( {\sum\limits_{s:{j \in s}}{x_{s}(t)}} \right)}} & (6)\end{matrix}$where the summation is over all routes ξ which contain resource j andwhere 4 is the reactivity parameter, as discussed below.

It is assumed above that r ranges over R and j over the set J.

As mentioned previously the prices p_(j)(·) need not be prices in thestrict sense of the word. The may, as mentioned, represent the level ofcongestion feedback from the network via the metering module 14.

It is observed that when ξ=0, the behaviour of the ξ algorithm isidentical to that of the primal algorithm. However, when ξ is set to avalue greater than zero, the algorithm is more aggressive than astandard additive increase, multiplicative decrease (AIMD) algorithm,and more resembles TCP's behaviour during “slow-start”. On the otherhand, when ξ is less than zero, the transfer rate is kept almostconstant, changing very slowly indeed. A more detailed analysis of howthe algorithm's behaviour depends on ξ is given below.

Stability and Fairness of the ξ Algorithm

Stability and fairness are two important criteria applied to congestionalgorithms to assess their performance.

An algorithm is regarded as being stable if it has a stable operatingpoint, that is a situation in which the transfer rate is kept constantunder constant network conditions. An algorithm is regarded as havingglobal stability if the stable operating point is reached automaticallyafter a certain amount of time. Furthermore, an algorithm is regarded ashaving local stability if, after a stable situation has been reached,small perturbations of the network conditions, do not affect the stableoperating point. And finally, assuming that an algorithm will convergeto a stable operating point, what is the rate of convergence, that ishow long does it take before a stable situation is reached.

The concept of fairness pertains to situations where a number of flowsshare network resources. In real life situations, these resources aregenerally limited. Fairness is concerned with each flow getting its“fair share” of the available resources. What exactly is meant by “fair”depends on the sort of fairness used, as there are different criteriafor assessing fairness. The type of fairness used to assess the 4algorithm is proportional fairness.

The inventors have shown that the ξ algorithm exhibits good stabilityand fairness. These two properties were considered by Kelly et al in “FP Kelly, A K Maulloo, and D K H Tan, Rate control for communicationnetworks: Shadow prices, proportional fairness and stability, Journal ofthe Operational Research Society 49 (1998), no. 3, 237-252”. Theinventors have applied the criteria of stability and proportionalfairness defined in Kelly et al's paper to the ξ algorithm.

In order to appreciate how the stability of the ξ algorithm has beendetermined theoretically, Lyapunov's second method is referred to. Forthe sake of completeness a brief discussion of Lyapunov's second methodis given below. Reference is made to “William E Boyce and Richard CDiPrima, Elementary differential equations and boundary value problems,6^(th) edition, John Wiley & Sons, Inc” for a fuller explanation of thismethod.

Lyapunov's second method is used to establish the stability or otherwiseof systems of differential equations, such as those set out above inequations (5) and (6) representing the present invention, and is asfollows: Given an autonomous system of differential equations

$\begin{matrix}{{\frac{\mathbb{d}x_{1}}{\mathbb{d}t} = {F_{1}(x)}},{\frac{\mathbb{d}x_{2}}{\mathbb{d}t} = {F_{2}(x)}},{{\ldots\mspace{11mu}\frac{\mathbb{d}x_{n}}{\mathbb{d}t}} = {F_{n}(x)}}} & (7)\end{matrix}$and a function V(x), defined on some domain D containing the origin,define the function V^(Y):

$\begin{matrix}{{V^{\overset{\prime}{Y}}(x)} = {{\frac{\partial V}{\partial x_{1}}(x){F_{1}(x)}} + {\frac{\partial V}{\partial x_{2}}{F_{2}(x)}} + \ldots + {\frac{\partial V}{\partial x_{n}}(x){F_{n}(x)}}}} & (8)\end{matrix}$Note that V^(Y) depends on the system of differential equations set outin equations (7). For convenience, the following definition isintroduced:

-   Lyapunov function: consider the system of differential equations (7)    and assume that it has an isolated critical point {circumflex over    (x)}. A function V(x) that is continuous, has continuous partial    derivatives, has a global maximum at {circumflex over (x)}, and for    which {dot over (V)}(x-{circumflex over (x)}) is positive definite    on some domain D containing the origin, is called a Lyapunov    function for the autonomous system represented by equations (7).

Using this definition the following theorem can be stated (proofomitted):

-   Theorem 1: suppose that the autonomous system represented by    equations (7) has an isolated critical point {circumflex over (x)}.    If there exists a Lyapunov function V for this system, then    {circumflex over (x)} is an asymptotically stable critical point. If    the function {dot over (V)}(x−{circumflex over (x)}) given in the    definition above is positive semidefinite instead of positive    definite, then the origin is a stable critical point.

To assess the stability of the ξ algorithm Kelly's approach was used.Thus, the following formula is defined:

$\begin{matrix}{{U(x)} = {{\sum\limits_{r \in R}{w_{r}\ln\; x_{r}}} - {\sum\limits_{j \in J}{\int_{0}^{\sum\limits_{s:{j \in s}}x_{s}}{{p_{j}(y)}\ {\mathbb{d}y}}}}}} & (9)\end{matrix}$

Where U(x) is the user's utility function, from which the demandfunction, as discussed above, is derived.

It is assumed that w_(r)>0, r∈R, and that for j∈J the functionsp_(j)(y), where y≧0, are non-negative, not identically zero, continuous,and increasing.

The following Theorem 2 is proposed: the continuous, strictly concavefunction U(x) is a Lyapunov function for the system of differentialequations (5) and (6). The unique value x maximising U(x) is anasymptotically stable point of the system.

The following proof is given: it follows from the assumptions on w_(r),r∈R, and p_(j), j∈J. that U(x) is strictly concave on x≧0 with aninterior maximum. Hence, the maximising value of x, which we shall call{circumflex over (x)}, is unique.

Observe that U has continuous partial derivatives, and that

$\begin{matrix}\begin{matrix}{{\frac{\mathbb{d}}{\mathbb{d}t}{U\left( {x(t)} \right)}} = {\sum\limits_{r \in R}{\frac{\partial U}{\partial x_{r}}\frac{\mathbb{d}}{\mathbb{d}t}{x_{r}(t)}}}} \\{{= {\kappa{\sum\limits_{r \in R}{\frac{{x_{r}(t)}^{\xi}}{x_{r}(t)}\left( {w_{r} - {{x_{r}(t)}{\sum\limits_{j \in r}{p_{j}\left( {\sum\limits_{s:{j \in s}}{x_{s}(t)}} \right)}}}} \right)^{2}}}}},}\end{matrix} & (10)\end{matrix}$establishing that

$\frac{\mathbb{d}}{\mathbb{d}t}{U\left( {{x(t)} - \hat{x}} \right)}$is a positive definite on some domain containing the origin.

It is thus shown that U is a Lyapunov function for the systemrepresented by equations (5) and (6).

Application of Theorem 1 yields the second part of the Theorem.

To assess the fairness of the ξ algorithm the following Kelly definitionof proportional fairness was used.

Suppose that the network has a set of J resources, and let c_(j) be thefinite capacity of resource j, for jεJ. Further more, take R⊂P(J), theset of possible routes, and x_(r),rεR the transfer rate of the flowthrough route r. Finally we define A=(A_(jr),jεJ,rεR), whereA _(jr)=0 if j∉r and 1 if jεr. (11)

A vector of sending rates x=(x_(r),rεR) is feasible if x≧0 and Ax ≦c.

Proportional fairness is defined as follows: A vector of rates x isproportionally fair if it is feasible, and if for any other feasiblevector {circumflex over (x)}, the aggregate of proportional changes iszero or negative:

$\begin{matrix}{{\sum\limits_{r \in R}\frac{{\hat{x}}_{r} - x_{r}}{x_{r}}} \leq 0.} & (12)\end{matrix}$

Without showing proof, the following Theorem 3 is stated from “Jean-YvesLe Boudec, Rate adaptation, congestion control and fairness: Atutorial.”.

Theorem 3: For every network situation there exists a uniqueproportionally fair allocation. It is obtained by maximising

$\sum\limits_{r \in R}{\ln\;{x_{r}.}}$

Theorem 3 is particularly useful because it gives a practical way ofcomputing a proportionally fair allocation. Simply maximising thefunction

$\sum\limits_{r \in R}{\ln\;{x_{r}.}}$suffices

FIG. 3 illustrates proportional fairness using a network with tworesources 300, 302 and three users 304, 306 and 308. Both resources 300,302 have capacity 12 (arbitrary units). The proportionally fairallocation is shown: user 304 has 4 units, users 306 and 308 have 8units. Proportional fairness gives priority to small flows.

An extension to the proportional fairness concept is the idea ofweighted proportion fairness. The definition is as follows: A vector ofrates x is proportionally fair if it is feasible, and if for any otherfeasible vector {circumflex over (x)}, the aggregate of weightedproportional changes is zero or negative:

$\begin{matrix}{{\sum\limits_{r \in R}{w_{r}\frac{{\hat{x}}_{r} - x_{r}}{x_{r}}}} \leq 0} & (13)\end{matrix}$with w=(w_(r),rεR) a vector of weights, n.b. w here is not to beconfused with the willingness to pay, shortened to w.

Theorem 3 can be adapted to cover weighted proportional fairness. It isnow necessary to maximise

$\sum\limits_{r \in R}{w_{r}\ln\;{x_{r}.}}$It is to be noted that the uniqueness of the solution is not guaranteedany longer, but depends on the weighting vector, w.

Theorem 4: the functions p_(j),j∈J, may be chosen such that the vector xmaximising U(x) approximates arbitrarily closely a vector of rates thatis weighted proportionally fair, with vector of weights w.

The following proof of Theorem 4 is given: let the functions p_(j),j∈J,be defined as

$\begin{matrix}{{p_{j}(y)} = {\left( {y - c_{j} + ɛ} \right)^{+}/ɛ^{2}}} & (14)\end{matrix}$where pj is a price function and E dictates the slope of the pricefunctions. (The superscript+indicates that if the quantity within thebrackets has a negative value, then it takes the value zero, and if thequantity within the brackets is positive, then it keeps its positivevalue.)

These functions are continuous. As ε→0, the vector maximising U(x)approximates arbitrarily closely the solution of the fairness problem

$\begin{matrix}{\max{\sum\limits_{r \in R}{w_{r}\ln\; x_{r}}}} & (15)\end{matrix}$subject to Ax≦c over x≧0.

Hence, by Theorem 3, set out above, x is proportionally fair per unitcharge.

It is important to note that both Theorems 2 and 4 remain valid when adifferent value for ξ is taken for each route or user, that is takingξ=(ξ_(r)),r∈R instead of just ξ.

The ξ algorithm and phases

The ξ algorithm has the distinct advantage over other equation basedcongestion algorithms depending on its implementation discussed below,of weighting the data rate to be requested by a variable parameter, ξ.This enable, for example, the ξ algorithm to operate in differentphases, i.e. depending on the network conditions at a particular time,its reaction to the particular conditions will be different, allowing itto adapt, and to ultimately cause data in the network to be handled moreefficiently. The phase of the algorithm is determined by the value of ξ.The switching from one phase to another depends on network and userdefined conditions. The present invention based on an assessment ofthese conditions causes the phase switch to occur automatically, to thusensure a more efficient resource management. An embodiment showing thephase switch is shown in FIG. 5.

In the embodiment discussed below with reference to FIG. 4, ξ is aweighting variable parameter.

In the embodiments discussed below with reference to FIG. 5, ξ takes oneof two values depending on the network conditions and the user'swillingness to pay. ξ is not however, limited in this respect and cantake an infinite number of values. In this section the behaviour of theξ algorithm is observed with respect to a limited small subset ofexamples where ξ has the value 0, −1 and +1. Also discussed in thissection are the network and user defined conditions which apply to causethe algorithm to switch phases, ie. the conditions that apply to cause ξto change value. By responding to network conditions, the change in theselection of the value of ξ will change the behaviour of the network,and in particular, as discussed above with reference to FIG. 1 and belowwith reference to FIG. 5, the requested data rate that is sent to acontent provider.

In the first of the examples, ξ is selected to be equal to zero. Whenξ=0, the algorithm behaves in the same way as the primal algorithm.

In the second example, ξ is set to be equal to +1. It was mentionedearlier with reference to the prior art, that one of the problems of theprimal algorithm is slow convergence due to the absence of a mechanismlike slow-start in TCP. Setting ξ=1 solves this problem: it provides aphase in which the transfer rate increases exponentially. This causesthe algorithm to act “aggressively” to generate rapidly changing datarate requests which are sent to the content provider. This phase isparticularly useful at the beginning of a data download, where the userwill want to go from zero data rate request to a stable downloading datarate as quickly as possible. The proof in Theorem 4 with respect to thestability does not depend upon the value of ξ, so in theory theaggressive rate control strategy that is the result of setting ξ to +1does not compromise stability.

In the third example, ξ is set to −1. Whereas ξ=1 results in aggressiverate changes, setting ξ=−1 has exactly the opposite effect: the transferrate will be adapted extremely slowly. This means that the convergencewill be slow, but once equilibrium is reached, small perturbations willhave little or no effect. In other words the local stability will beextremely good. This situation is very desirable for some applications,notably real-time video or audio streams. Thus, this phase is veryuseful in situations where no drastic adaptation of the transfer rateseems to be required, and the only changes are due to smallperturbations in shadow price information around an equilibrium.

The present exemplary embodiment allows for the possibility of setting ξto 0 or +1 when relatively rapid changes of data rate request arerequired, for example to get sufficiently fast convergence, whilesetting ξ=−1 at other times to satisfy the needs of several differenttypes of applications, for example, real time data download applicationsand multimedia applications.

The invention is not limited with respect to what determines the valueof ξ. For example, however, one set of parameters to apply when changingξ=1 or 0 to ξ=−1 is in response to the marking rate which gives rise tocongestion indication and the price charged by the network. When thatprice is within a tolerance parameter, beta, close to the price the useris willing to pay, ξ can be set to −1 because when the price charged ismore or less the same as the price the user is willing to pay, the datarate request should be kept as close to the user's willingness to pay aspossible. This mechanism is explained in more detail with reference toFIGS. 4 and 5.

A preferred implementation of the invention is in software: the ratecontroller 16 acts as a single middleware that runs in the background ona user's machine. It captures a user specified buying policy from thepolicy selector 20 along with the real-time dynamic pricing informationfrom the marking module 14 and produces a requested data rate using theξ algorithm described above.

The form in which the ξ algorithm was present above, as a system ofdifferential equations, makes it unsuitable to be implemented insoftware directly. Computers provide a discrete environment and cannotcope with the inherently continuous nature of a differential equation.To implement the invention in software, it is therefore necessary toinclude a discretisation step and to transform the differentialequations into difference equations.

This results in equation (4), which may also be written as the followingsystem:

$\begin{matrix}{{{x_{r}\left\lbrack {t + 1} \right\rbrack} = {{x_{r}\lbrack t\rbrack} + {{\delta\kappa}\;{x_{r}\lbrack t\rbrack}^{\xi}\left( {w_{r} - {{x_{r}\lbrack t\rbrack}{\sum\limits_{j \in r}{m_{j}\lbrack t\rbrack}}}} \right)}}}{where}{{{m_{j}\lbrack t\rbrack} = {p_{j}\left( {\sum\limits_{s:{j \in s}}{x_{s}\lbrack t\rbrack}} \right)}},}} & (16)\end{matrix}$and δ is the discretisation step size. Other techniques for solvingdifferential equations numerically, for example numerical integration,could also be used.

The step size δ is important. It should not be too small, because ofrestrictions on computing power and the availability of price feedback,but a step size that is too large will result in errors. Preferably, thestep size δ is chosen in accordance with the frequency of the pricefeedback availability. This will vary from network to network dependingon the marking rate in the network. The period over which marks arecollected and counted should not be too short, for then the number ofmarks will always be either 0 or 1, or perhaps a little higher, and mostof the price information will then be conveyed by the number of marks inany one period. On the other hand, from the point of view of the ratecontrol algorithm, it is desirable to have price feedback as frequentlyas possible.

Those skilled in the art will have no difficulty in providing a programto collect the parameters discussed above, applying the algorithm tothose parameters to generate the network resource control describedabove, and shown step by step in FIGS. 4 and 5.

The procedure for implementing resource control using the ratecontroller of the present invention is shown in FIGS. 4 and 5. The ratecontroller 16 functions according to the ξ algorithm shown in equations(4) and alternatively notated in equation (16).

As mentioned above, the rate controller 16 preferably forms part of theDPH agent 8 shown in FIG. 1.

With reference to FIG. 4, at step 41, the indication of the congestionis obtained. In step 42, the willingness to pay is selected in responseto the price reactor as described with reference to FIG. 1. In step 43the dynamic input values are retrieved: the data rate, x_(n) isretrieved from the memory 17 in the rate controller 16 and theindication of congestion is obtained from the price reactor 18 if notalready retrieved. In step 58, the difference, D, between the willingness to pay and m*x_(n) is computed. In step 44, the data rate to berequested is determined as a function of the indication of thecongestion and the willingness to pay. In step 45, the output of step 44is weighted by a variable parameter, xi.

In step 46 the data rate to be requested is communicated to the contentprovider. In particular, this is done via the stream adaptation module24.

In step 47, it is ascertained whether or not the data transfer iscomplete. If it is complete, the algorithm ends. If the transfer is notcomplete, it is ascertained in step 48 whether the willingness to pay,w, is to remain the same, or whether this user determined parameter isto change. If the willingness to pay is to remain unchanged, thealgorithm proceeds directly to step 43 for the next iteration. If thewillingness to pay is changed, the algorithm returns to step 41.

A further embodiment is now described with reference to FIG. 5. At step50 the adaptation gain factor, kappa, and the discretisation constant,delta, are set. As mentioned, the selection of kappa will reflect acompromise reached between reactivity, also referred to as convergenceand stability. The higher the value of kappa the ampler the reaction,and the greater the risk of instability. The lower the value of kappa,the more stable the data rate, and the greater the risk of not adaptingenough. The choice of the value of delta will depend on the computingresource available, the marking rate and the frequency of the pricefeedback. At step 50, the constant beta is also set. This constant is atolerance parameter reflecting the limits with respect to the networkdetermined parameter, that is the price derived from the congestionindicators, within which the user determined parameter, that is thewillingness to pay, should fall if the requested data rate is to remainstable. If the willingness to pay with respect to the price does fallwithin the tolerance parameter, xi is set to zero. If, on the otherhand, the willingness to pay with respect to the price does not fallwithin the tolerance parameter, xi is set to 1 or to any other smallpositive value, to cause the algorithm to react speedily to request ahigher data rate. The value of beta will depend on the network, andpreferably lies between 1 and 10%. For example, if beta is set to 0.05,i.e. 5%, then the values obtained in step 60 is [0.95*w;1.05*w], or inother words, when that value differs from w by less than 5%, xi is setto 0 for a gentle adaptation, otherwise xi is set to 1 or a smallpositive value for the aggressive adaptation. In the particular examplegiven above, the value of xi is a step function, however, how xi variesis not limited, and xi may also vary continuously, for example, with thedifference between the price and the willingness to pay.

The values kappa, delta and beta do not have to remain fixed throughoutthe session or download. However, usually, they will remain fixed duringone session.

In step 52, the price estimate, g, also referred as the congestioncharge, is retrieved from the price reactor. It is noted that the priceestimate μ may also be referred to as the congestion charge. In step 54the willingness to pay, w, is set in response to the price reactor asdescribed with reference to FIG. 1. In step 56 the dynamic input valuesare retrieved: the data rate, x_(n) is retrieved from the memory 17 inthe rate controller 16 and the price estimate, m, from the price reactor18 if not already retrieved. In step 58, the difference, D, between thewillingness to pay and μ*x_(n) is computed. The product of μ*x_(n), isthe indication of congestion.

In step 60, it is established whether the difference, D, lies within therange 1-beta*w and 1+beta*w. If D does lie within the range then xi isset to 0 in step 64. If D does not lie within the range, xi is set to 1or a small positive value in step 62. Once xi is set, the next step 66is to compute the difference, D, multiplied by x_(n) to the power xi,that is D* x_(n) ^(ξ). In step 68, the output from step 66 is multipliedby the gain factor, kappa, and the time step, delta. In step 70, theoutput from step 68 is added to the data rate, x_(n), to obtain therequested data rate, x_(n)+1. In step 74, the rate controller memory 17is updated. X_(n) is replaced with x_(n+1), and set as x_(n). In step 72the data rate to be requested, x_(n+1), is communicated to the contentprovider. In particular, this is done via the stream adaptation module24. This may be communicated to the stream adaptation module via thequality of service controller 15.

In step 76, it is ascertained whether or not the data transfer iscomplete. If it is complete, the algorithm ends. If the transfer is notcomplete, it is ascertained in step 78, whether time step, delta, haselapsed since this step was last carried out. If the time period, delta,has not elapsed, the algorithm waits until it has. If the time periodhas elapsed, in step 80, it is ascertained whether the willingness topay, w, is to remain the same, or whether this user determined parameteris to change. If the willingness to pay is to remain unchanged, thealgorithm proceeds directly to step 56 for the next iteration. If thewillingness to pay is changed, the algorithm returns to step 52.

With reference to FIG. 6 the procedure for implementing resource controlaccording to a different algorithm using the rate controller is shown.The rate controller 16 is comprised in the DPH agent 8 as for theprevious algorithm and as shown in FIG. 1, but generates a request fordata rate according to a different algorithm.

As with the xi algorithm, the algorithm is a discretisation of a systemof differential equations. Hereinafter the algorithm, whose procedure isshown in FIG. 5 is referred to as the scalable algorithm.

The system of differential equations representing the scalar algorithmis:

$\begin{matrix}{{{\frac{\mathbb{d}}{\mathbb{d}t}{x_{r}(t)}} = {\kappa\left( {\frac{{wtp}_{r}(t)}{\sum\limits_{j \in r}{\mu_{j}(t)}} - {x_{r}(t)}} \right)}},} & (17)\end{matrix}$for r∈R.

This system of differential equations was developed from the willingnessto pay (w). As mentioned previously, the willingness to pay representsthe amount a user is willing to pay for the service provided by thenetwork. In general this amount can vary over time, so willingness topay becomes a function of time. The scalar algorithm, rather than takinga single data stream, describes the overall behaviour of the network.

Again, as with the xi algorithm, the form in which the scalar algorithmwas presented above in equation (17), as a system of differentialequations, makes it unsuitable to be implemented in software directly.Computers provide a discrete environment and cannot cope with theinherently continuous nature of a differential equation. To implementthe invention in software, it is therefore necessary to include adiscretisation step and to transform the differential equations intodifference equations. This results in equation (18), which may also bewritten as the following system:

$\begin{matrix}{x_{n + 1} = {x_{n} + {\delta*\kappa*\left( {\frac{w}{\mu} - x_{n}} \right)}}} & (18)\end{matrix}$where the parameters are the same as those referred to above withrespect to the xi algorithm.

The advantage of a rate controller implemented according to the scalaralgorithm is that the convergence properties depend only on the relativevariation of the congestion charge (μ), that is, it will take as long tosettle to the new equilibrium when the congestion level goes from 9% to12% as when the congestion goes from 3% to 4%.

The implementation of this algorithm is now described with reference toFIG. 5. At step 90, the gain factor, kappa, and the time step, delta,are set. At step 92, the price estimate (μ) is retrieved from the pricereactor 18. At step 94, the willingness to pay (w) is set in response tothe price estimate (m). At step 96 the dynamic input values areretrieved. The data rate (x_(n)) is retrieved from the memory 17 in therate controller 16 and the price estimate (μ) is retrieved from thememory of the price reactor 18. At step 98, the difference (D) betweenthe willingness to pay (w) divided by the price estimate (μ) and thedata rate (x_(n)) is computed. At step 100, the output from the previousstep 98 is multiplied by the gain factor (kappa) and the time step(delta). A step 102, the output from previous step 100 is added to thedata rate (x_(n)) to obtain the request data rate (x_(n+1)). At step 104the memory 17 in the rate controller 16 is updated. X_(n) is replacedwith x_(n+1). At step 106, the value of x_(n+1) is communicated to thestream adaptation module 24. At step 108, it is ascertained whether thedata transfer is complete. If it is complete, the program stops. If itis not complete, at step 110, it is ascertained whether time step,delta, has elapses since this step was last carried out. If the timeperiod, delta, has not elapsed, the algorithm waits until it has. If thetime period has elapsed, in step 112, it is ascertained whether thewillingness to pay, w, is to remain the same, or whether this userdetermined parameter is to change. If the willingness to pay is toremain unchanged, the algorithm proceeds directly to step 96 for thenext iteration. If the willingness to pay is changed, the algorithmreturns to step 92.

Unless the context clearly requires otherwise, throughout thedescription and the claims, the words “comprise”, “comprising” and thelike are to be construed in an inclusive as opposed to exclusive orexhaustive sense; that is to say, in the sense of “including, but notlimited to”.

1. A method of controlling the rate of data transmission from a sourceof data to a user via a communications link, wherein processing meansare provided to generate a signal representing a rate request which willbe used in determining the rate at which data will be transmitted fromthe source to the user, said processing means generating the signal by:obtaining a congestion charge on said communications link, selecting avalue indicative of the user's willingness to pay for a giventransmission data rate, determining the rate to be requested using thefollowing iterative equation:x_(n+1)=x_(n)+delta*kappa*x_(n) ^(ξ)(w−x_(n)*μ) where x_(n) is the datatransmission rate (bits per second) as calculated at an nth iteration;and x_(n+1) is the rate to be determined; x_(n)*μ is the charge to theuser indicative of amount of congestion and is the product of x_(n) andcongestion charge μ; w is the willingness to pay; delta is the timeelapsed between two iterations; kappa is a constant gain parameter; andξ (xi) is a reactivity parameter which varies during the datatransmission to control the speed with which said rate requests areadapted in response to changing congestion conditions as a function ofthe indication of a difference between the user's willingness to pay anda congestion cost which is the product of congestion charge and apreviously determined data transmission rate, said difference beingweighted by a variable parameter, the processing means thereaftercommunicating the signal to the source of data and the rate of the datatransmission from the data source to the user then being controlled onthe basis of the signal.
 2. A method according to claim 1, wherein saidreactivity parameter assumes discrete values.
 3. A method according toclaim 1, wherein the value of said reactivity parameter variescontinuously.
 4. A method according to claim 1, wherein the value ofsaid reactivity parameter varies in accordance with the differencebetween the user's willingness to pay and the indication of the amountof congestion.
 5. A method according to claim 1, wherein: the value ofsaid reactivity parameter is set depending on the indication ofcongestion or the user's willingness to pay.
 6. A method according toclaim 4, wherein if the difference between the indication of the amountof congestion and the user's willingness to pay falls within apredetermined range a first data rate is requested, and if thedifference between the indication of the amount of congestion and theuser's willingness to pay falls outside the predetermined range a seconddifferent data rate is requested.
 7. A method according to claim 4wherein said parameter ξ is a step function assuming the value 0 forvalues of said difference larger than a threshold value, and assumingthe value 1 for values of said difference smaller than said thresholdvalue.
 8. A method according to claim 1 wherein obtaining a congestioncharge includes determining a marking rate m of incoming datatransmitted on said communications link and wherein said congestioncharge is determined from said marking rate.
 9. A rate controller forcontrolling the rate of data transmission from a source to a user via acommunications link, said rate controller including processing means forgenerating a signal representing a rate request which will be used indetermining the rate at which data will be transmitted from the sourceto the user, said processing means including: means for obtaining acongestion charge for said communications link, selecting means forselecting a value indicative of the user's willingness to pay for agiven transmission data rate, determining means adapted to determinesaid rate to be requested using the following iterative equation:x _(n+1) =x _(n)+delta*kappa*x _(n) ^(ξ)(w−x _(n)*μ) where x_(n+1) isthe data transmission rate (bits per second) as calculated at an nthiteration and x_(n+1) is the rate to the determined; x_(n)*μ is thecharge to the user indicative of amount of congestion and is the productof x_(n) and congestion charge μ; w is the willingness to pay selectedby selected means in response to a determined transmission rate; deltais the time elapsed between two iterations; kappa is a constant gainparameter; and ξ (xi) is a reactivity parameter which varies during thedata transmission to control the speed with which said rate requests areadapted in response to changing congestion, and means for communicatingthe signal to the source, wherein the rate of the data transmission fromthe source to the user is controlled on the basis of the signal.
 10. Arate controller according to claim 9, wherein said determining means isadapted to, determine the difference between the user's willingness topay and the indication of the amount of congestion, and vary the valueof the reactivity parameter in accordance with the difference.
 11. Arate controller according to claim 9, wherein said determining meansdetermines a first rate to be requested if said difference between theindication of the amount of congestion and said selected value fallswithin a predetermined range, and a second different data rate to berequested if the difference between the indication of the amount ofcongestion and the value falls outside the predetermined range.
 12. Arate controller according to claim 9, wherein the value of saidreactivity parameter is set depending on the indication of congestion orthe user's willingness to pay.
 13. A rate controller according to claim9, wherein said means for obtaining a congestion charge comprisesmetering means for determining a marking rate of incoming datatransmitted on said communications link.
 14. A rate controller accordingto claim 10, wherein said reactivity parameter is a step functionassuming the value 0 for values of said difference larger than athreshold value, and assuming the value 1 for values of said differencesmaller than said threshold value.
 15. A computer readable mediumencoded with computer executable instructions executable by theprocessor to perform the steps of claim 1.